In an access and edge network, PIM-SM protocol (RFC4601, Protocol Independent Multicast-Sparse Mode: Protocol Specification (Revised)) is supported in edge nodes and core network nodes. A Rendezvous Point (RP) is the root of PIM-SM share tree. The anycast RP protocol using the PIM protocol (RFC4610, Anycast-RP Using Protocol Independent Multicast) is designed to provide load balancing and failover for the RP. However, there is no cooperation mechanism among anycast RPs in the protocol when sending Register-Stop Messages, which may result in subscriber terminals under some anycast RPs having interrupted multicast service and bandwidth waste among anycast RPs due to trashy Register Messages.
According to RFC4610, the RPs in an anycast group work as follows.
As shown in FIG. 1, RP1, RP2 and RP3 represent three RPs in an anycast group; each of R1, R1′, R2 and R3 is a subscriber terminal in the group; DR stands for a Designated Router (DR) directly attached to a source S1 which sends information to the anycast group. It is assumed that RP1, RP2 and RP3 are all assigned with the same IP address which is used as the anycast RP address and called an IPA.
When S1 starts sending source data traffic, the flow to be obeyed is as follows.
1. S1 sends a multicast packet, and the DR directly attached to the S1 forms a PIM Register message to send to the anycast RP address (IPA) through adding a unicast header to the multicast packet. The unicast routing system delivers the PIM Register message to the nearest RP, in this case RP1.
2. The RP1 uses its own IP address as the source address, and sends the Register message from the DR to the RP2 and RP3, respectively.
3. The RP1 sends a Register Stop message to the DR.
4. When receiving the Register message from the RP1, the RP2 and the RP3 send the Register Stop message to the RP1 respectively.
5. The RP1 receives the Register Stop messages from the RP2 and the RP3, without any processing.
The problems in the above procedure comprise: firstly, the RP1 sends the Register Stop message to the DR without considering that the RP2 and RP3 may still need the Register message from the DR, since the shortest multicast delivery paths (that is, the Shortest Path Tree) from the DR to the RP2 and the RP3 may haven't been established, which makes the subscriber terminals' multicast service desultory. Secondly, the RP1 sends Register messages to RP2 and RP3 without considering that RP2 and RP3 may not need them anymore recently, because the shortest multicast delivery paths from the DR to the RP2 and the RP3 may have been established or there is no subscriber terminal under RP2 or RP3, which may results in waste of RP1's CPU resource and bandwidth among anycast RPs.